FIG. 1 shows in a simplified manner an example of a principle on how service frames are forwarded between a UE and a service network based on the current 3G/4G core network architecture. All service frames are forwarded along an end-to-end bearer between the user equipment (UE) and a single mobile gateway (GW). The GW is selected based on an access point name (APN) as specified by the UE or stored in the subscription profile.
For the forwarding purpose, two tunnel end points (TEP) are maintained for a bearer in the network. If the UE sends a service frame to the base station, the base station encapsulates this service frame with a GTP-u (GTP, GPRS (General Packet Radio Service) Tunnel Protocol) protocol header using ‘TEP b’ and sends the encapsulated frame into the transport network underlay which routes it to the gateway. In downstream direction, the GW encapsulates a service frame destined for the UE with a GTP-u protocol header using ‘TEP a’ and sends the encapsulated packet into the transport network underlay which routes the packet to the base station. The base station looks up the UE and radio access bearer (RAB) associated with ‘TEP a’ and forwards the service frame towards the UE.
FIG. 2 shows the same principle, but now applied to access a local service.
It is important to note, that in 3G/4G networks it is not possible to access two service networks, e.g. a local service network and central service network, each with its own gateway, neither by using the same bearer nor by using a single PDN (Packet Data Network) connection. It would only be possible by setting up two simultaneous PDN connections, which has the disadvantage of becoming visible to the UE and its application software.
Specifically, it is not possible to support in 3G/4G a use case as shown in FIG. 3. This use case represents a multi edge scenario with a central edge site for accessing the Internet and with a local edge for accessing the cached content of a content distribution network (CDN). The service topology involves now three tunnel end points. Both gateways need to know about ‘TEP a’ to forward service frames to the UE. Additionally the base station (BS) needs to have a service processing function, which examines the destination IP address of service frames sent by the UE and decides if to encapsulate the service frame with a GTP header using ‘TEP b’ or using ‘TEP c’.
FIG. 4 shows another service topology also with three tunnel end points, but now only involving UE and no network gateways. In this use case, the three UEs can communicate directly with each other without involving a gateway. Each base station needs to select the appropriate GTP tunnel end point in dependence of the destination IP address of a service frame received from the UE over the radio. Service topologies like shown in FIG. 4 are needed to support low latency virtual private network services, e.g. as being required for vehicular ad hoc networking (VANET).
Virtual private networking (VPN) service means that users of this service can use their own addressing scheme without the need to coordinate with other services or networks. Low latency implies that forwarding in the user plane shall minimize delay by forwarding packets on a shortest path, avoiding intermediate forwarding hops as far as possible.
In addition to lowest latency, mission critical services require highest service availability and reliability even in case of partial network failures. This requirement favours a decentralized architecture in user and control plane avoiding by design single point of failures.
FIG. 5 combines the use case of FIG. 4 with that of a central gateway. While UE a, UE b and UE c can directly communicate with each other, they are also able to communicate with a central service network using a mobile gateway GW. The figure also indicates on the bottom a set of UEs which only can communicate via the central GW as it is the case in 3G/4G networks. These UEs at the bottom cannot directly send or receive service frames to or from other UE.
FIGS. 6 and 7 show typical examples of LTE distributed u-plane implementations. These architectures require interconnecting UEs behind the PGW-D (PGW, PDN Gateway) function or egress SDN FE (Software Defined Network Forwarding Element) (providing SGi), i.e. in the internet or a private IP network (cf. documents [1] and [2]).
FIG. 8 illustrates an alternative solution for providing VPN services, specifically a L3VPN (Layer 3 Virtual Private Network) implementation where the Provider Edge router is included in LTE P-GW (PGW-D or egress SDN FE in FIGS. 6 and 7). The disadvantage of this solution is that each UE is still anchored to a stationary user plane gateway and therefore handovers will result in inefficient routing and traffic trom boning.